The present invention relates generally to information processing environments and, more particularly, to employing user-directed services for controlling system operation in a data processing system, such as a Database Management System (DBMS).
Computers are very powerful tools for storing and providing access to vast amounts of information. Computer databases are a common mechanism for storing information on computer systems while providing easy access to users. A typical database is an organized collection of related information stored as "records" having "fields" of information. As an example, a database of employees may have a record for each employee where each record contains fields designating specifics about the employee, such as name, home address, salary, and the like.
Between the actual physical database itself (i.e., the data actually stored on a storage device) and the users of the system, a database management system or DBMS is typically provided as a software cushion or layer. In essence, the DBMS shields the database user from knowing or even caring about underlying hardware-level details. Typically, all requests from users for access to the data are processed by the DBMS. For example, information may be added or removed from data files, information retrieved from or updated in such files, and so forth, all without user knowledge of underlying system implementation. In this manner, the DBMS provides users with a conceptual view of the database that is removed from the hardware level. The general construction and operation of a database management system is known in the art. See e.g., Date, C., An Introduction to Database Systems, Volume I and II, Addison Wesley, 1990; the disclosure of which is hereby incorporated by reference.
DBMS systems have long since moved from a centralized mainframe environment to a de-centralized or distributed environment. One or more PC "client" systems, for instance, may be connected via a network to one or more server-based database systems (SQL database server). Commercial examples of these "client/server" systems include Powersoft.TM. clients connected to one or more Sybase SQL Server.TM. database servers. Both Powersoft.TM. and Sybase SQL Server.TM. are available from Sybase, Inc. of Emeryville, Calif.
Today, a schism exists in SQL database systems between "users" and "system." Users communicate with a SQL database server by issuing SQL commands. Often, a database vendor will provide an enhanced SQL syntax, such as TRANSACT-SQL (T-SQL) commands found in Sybase SQL Server. For its part in processing such commands, an SQL database server system may be viewed as a set of purpose-written functions, each of which accomplishes one task.
Both sides of this schism are inherently limited, since neither is all inclusive. In Sybase SQL Server, for instance, T-SQL cannot accomplish certain system tasks, such as formatting pages or directly accessing the system's transaction log. Further, purpose-written functions cannot construct and execute general-purpose queries. For example, system functions cannot process queries with either UNION or OR clauses. Additionally, because system functions are purpose-written, one must write a new function for every new purpose --the existing code cannot adapt to a different purpose.
Because of these limitations, present-day systems are inherently inflexible: the various pieces of these systems are limited by the support which has been built in for them. For instance, one area which is particularly limited is that of "upgrading"--that is, updating an existing installation so that it is usable by a newer version of the SQL database server (e.g., SQL Server). This problem will now be described in further detail.
With each new version of an SQL database server released, users must face the problematic task of upgrading existing databases. Often, the task requires adding new tables to the system. Existing tables and accompanying data structures often are changed as well. Changes may even be so drastic that the database system needs to update every data page in the user's database (i.e., rewrite these basic storage units which store tuple or record information).
In the past, one approach to addressing these problems was to employ a separate executable, an "upgrade utility." This standalone program had the task of collecting the knowledge of everything which changed between the different versions of the database server and issuing SQL command statements in order to effect the necessary changes. The approach was in itself problematic. Here, the utility ran as a "user," despite the fact it was inherently a highly-privileged user. This leads to further disadvantages. Upgrade steps were limited to that collection of things which could be expressed as SQL statements. If a task were not easily expressible as SQL, the database vendor had to extend the SQL grammar (e.g., Sybase T-SQL) with special statements to enable that task. Secondly, the SQL interface exposed internal information to customers. Because of the grammar extensions, customers could gain access to protected system functions and language extensions. This decreases system security, exposing the database to increased risk of extensive damage due to malicious or foolish tampering. Finally, the utility approach provided no authentication. Any user task that presented the correct profile to the database server was accepted as the "upgrade" task. Again, this compromises security, for instance, allowing a random user to masquerade as a privileged system task.
What is needed are methods providing some crossover between "users" and "system" parts in a database system. Preferably, such methods would be implemented by adapting existing machinery in current database systems. The present invention fulfills this and other needs.